home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-x400ops-postmaster-03.txt < prev    next >
Text File  |  1993-10-29  |  10KB  |  250 lines
  1.  
  2.           draft-ietf-x400ops-postmaster-03.txt        x400ops Working Group
  3.           INTERNET DRAFT                                       October 1993
  4.  
  5.  
  6.  
  7.                      Postmaster Convention for X.400 Operations
  8.  
  9.                             Wed Oct 27 22:24:08 CDT 1993
  10.  
  11.  
  12.                                   C. Allan Cargille
  13.                                University of Wisconsin
  14.                              Allan.Cargille@cs.wisc.edu
  15.  
  16.  
  17.  
  18.  
  19.  
  20.           This draft document is being circulated for comment.
  21.  
  22.           If consensus is reached it may be submitted to the RFC editor as
  23.           a Proposed Standard protocol specification, for use in X.400 in
  24.           the Internet.
  25.  
  26.           Please send comments to the author, or to the IETF OSI X.400
  27.           Operations Working Group mailing list
  28.           <ietf-osi-x400ops@cs.wisc.edu>.
  29.  
  30.           This document is an Internet Draft.  Internet Drafts are working
  31.           documents of the Internet Engineering Task Force (IETF), its
  32.           Areas, and its Working Groups.  Note that other groups may also
  33.           distribute working documents as Internet Drafts.
  34.  
  35.           Internet Drafts are draft documents valid for a maximum of six
  36.           months.  Internet Drafts may be updated, replaced, or obsoleted
  37.           by other documents at any time.  It is not appropriate to use
  38.           Internet Drafts as reference material or to cite them other than
  39.           as a "working draft" or "work in progress."
  40.  
  41.           Please check the I-D abstract listing contained in each Internet
  42.           Draft directory to learn the current status of this or any other
  43.           Internet Draft.
  44.  
  45.           Abstract:
  46.  
  47.                Both RFC822 and RFC1123 (Host Requirements) require that the
  48.                email address "postmaster" be supported at all hosts.  This
  49.                paper extends this concept to X.400 mail domains which have
  50.                registered RFC1327 mapping rules, and which therefore appear
  51.                to have normal RFC822-style addresses.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.           Cargille               Expires April, 1994               [Page 1]
  58.  
  59.  
  60.  
  61.  
  62.  
  63.           DRAFT              X.400 Postmaster Convention       October 1993
  64.  
  65.  
  66.           1.  Postmaster Convention in RFC822
  67.  
  68.           Operating a reliable, large-scale electronic mail (email) network
  69.           requires cooperation between many mail managers and system
  70.           administrators.  As noted in RFC822 [1], often mail or system
  71.           managers need to be able to contact a responsible person at a
  72.           remote host without knowing any specific user name or address at
  73.           that host.  For that reason, both RFC822 and the Internet Host
  74.           Requirements [2] require that the address "postmaster" be
  75.           supported at every Internet host.
  76.  
  77.           2.  Postmaster Convention and X.400
  78.  
  79.           However, RFC822 is not the only email protocol being used in the
  80.           Internet.  Some Internet sites are also running the X.400 (1984)
  81.           email protocol [3].  In the near future, the 1988 X.400 protocol
  82.           is also expected to be in use [4].  RFC1327 specifies how to map
  83.           between X.400 and RFC822 addresses [5].  When mapping rules are
  84.           used, addresses map cleanly between X.400 and RFC822.  In fact,
  85.           it is impossible to determine by inspecting the address whether
  86.           the recipient is an RFC822 mail user or an X.400 mail user.
  87.  
  88.           A paper by Rob Hagens and Alf Hansen describes an X.400 community
  89.           known as the "Global Open MHS Community" (GO-MHS) [6].  Many mail
  90.           domains in the GO-MHS Community have registered RFC1327 mapping
  91.           rules.  Therefore, users in those domains have RFC822-style email
  92.           addresses, and these email domains are a logical extension of the
  93.           RFC822 Internet.  It is impossible to tell by inspecting a user's
  94.           address whether the user receives RFC822 mail or X.400 mail.
  95.  
  96.           Since these addresses appear to be standard RFC822 addresses,
  97.           mail managers, mailing list managers, host administrators, and
  98.           users expect to be able to simply send mail to
  99.           "postmaster@domain" and having the message be delivered to a
  100.           responsible party.  When an RFC1327 mapping rule exists, the
  101.           X.400 address element corresponding to the left-hand-side
  102.           "postmaster" is "Surname=Postmaster" (both 1984 and 1988).
  103.           However, neither the X.400 protocols, North America X.400
  104.           Implementor's Agreements [7], nor the European X.400
  105.           Implementor's Agreements [8] require that "Surname=Postmaster"
  106.           and "CommonName=Postmaster" be supported.  (Supporting these
  107.           addresses is recommended in X.400 (1988)).
  108.  
  109.           For mapped X.400 domains which do not support the postmaster
  110.           address(es), this means that an address such as
  111.           "user@some.place.zz" might be valid, yet mail to the
  112.           corresponding address "postmaster@some.place.zz" fails.  This is
  113.           frustrating for remote administrators and users, and can prevent
  114.           operational problems from being communicated and resolved.  In
  115.           this case, the desired seamless integration of the Internet
  116.           RFC822 mail world and the mapped X.400 domain has not been
  117.           achieved.
  118.  
  119.  
  120.  
  121.           Cargille               Expires April, 1994               [Page 2]
  122.  
  123.  
  124.  
  125.  
  126.  
  127.           DRAFT              X.400 Postmaster Convention       October 1993
  128.  
  129.  
  130.           The X.400 mail managers participating in the Cosine MHS Project
  131.           discussed this problem in a meeting in June 1992 [9].  The
  132.           discussion recognized the need for supporting the postmaster
  133.           address at any level of the address hierarchy where these are
  134.           user addresses.  However, the group only required supporting the
  135.           postmaster address down to certain levels of the O/R Address
  136.           tree.  This approach solved part of the problem, but not all of
  137.           it.  A more complete solution is required.
  138.  
  139.           3.  Proposed Solution
  140.  
  141.           To fully achieve the desired seamless integration of email
  142.           domains for which RFC1327 mapping rules have been defined, the
  143.           following convention must be followed,
  144.  
  145.               If there are any valid addresses of the form
  146.               "user@domain", then the address "postmaster@domain" must
  147.               also be valid.
  148.  
  149.           To express this in terms of X.400:  For every X.400 domain for
  150.           which an RFC1327 mapping rule exists, if any address of the form
  151.  
  152.               Surname=User; <Other X.400 Address Elements>
  153.  
  154.           is a valid address, then the address
  155.  
  156.               Surname=Postmaster; <Same X.400 Address Elements>
  157.  
  158.           must also be a valid address.  If the X.400 system is running
  159.           X.400(1988), then the address
  160.  
  161.               CommonName=Postmaster; <Same X.400 Address Elements>
  162.  
  163.           must also be supported.  (Note that CommonName=Postmaster will
  164.           not be generated by RFC1327 mappings, but it is recommended in
  165.           the 1988 X.400 standard).
  166.  
  167.           To remain consistent with RFC822, "Mail sent to that address is
  168.           to be routed to a person responsible for the site's mail system
  169.           or to a person with responsibility for general site operation."
  170.           [10]
  171.  
  172.           3.1.  Software Limitations
  173.  
  174.           If software is unable to support this requirement, it should be
  175.           upgraded.  X.400 software developers are strongly encouraged and
  176.           requested to support forwarding mail to a centralized postmaster
  177.           mailbox in products.
  178.  
  179.           It may be possible to support forwarding postmaster mail to a
  180.           central mailbox in software packages which do not explicitly
  181.           support it by applying workaround solutions.  For example, some
  182.           packages support creating a mailing list for "postmaster" which
  183.  
  184.  
  185.           Cargille               Expires April, 1994               [Page 3]
  186.  
  187.  
  188.  
  189.  
  190.  
  191.           DRAFT              X.400 Postmaster Convention       October 1993
  192.  
  193.  
  194.           has one entry that points to the desired centralized postmaster
  195.           mailbox.  Alternatively, it may be possible to support a
  196.           postmaster address using the X.400 Autoforwarding feature.  The
  197.           software package may also support rewriting the address in some
  198.           other way.
  199.  
  200.           4.  Acknowledgements
  201.  
  202.           This document is a product of discussion and comments from the
  203.           IETF OSI X.400 Operations working group.  Helpful input was also
  204.           received from the European MHS Managers.  Special thanks to Marko
  205.           Kaittola and Erik Lawaetz for good criticism and helpful
  206.           discussion.
  207.  
  208.           5.  Author's Information
  209.  
  210.           Allan Cargille
  211.           Associate Researcher
  212.           Computer Sciences Department
  213.           University of Wisconsin-Madison
  214.           1210 West Dayton Street
  215.           Madison, WI   53706   USA
  216.  
  217.           Internet: cargille@cs.wisc.edu
  218.           X.400:    S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;
  219.  
  220.           Voice +1 (608) 262-5084
  221.           Fax   +1 (608) 262-9777
  222.  
  223.           6.  References
  224.  
  225.           [1]  RFC822
  226.  
  227.           [2]  RFC1123
  228.  
  229.           [3]  X.400 (1984)
  230.  
  231.           [4]  X.400 (1988)
  232.  
  233.           [5]  RFC1327
  234.  
  235.           [6]  presently draft-ietf-x400ops-mgtdomains-ops-06.txt
  236.  
  237.           [7]  NIST X.400 Implementors Agreements
  238.  
  239.           [8]  EWOS X.400 Implementors Agreements
  240.  
  241.           [9]  Minutes from June 1992 Cosine MHS Managers Meeting
  242.  
  243.           [10] RFC822, direct quote
  244.  
  245.  
  246.  
  247.  
  248.  
  249.           Cargille               Expires April, 1994               [Page 4]
  250.